如果有人擁有網站，速度很重要！這意味著如果加載緩慢，它會排斥潛在消費者，并降低轉化率。這對企業來說確實是一件大事，因為即使這種情況持續一段時間，它也無法發展。大量流量可能會導致服務器宕機，如果業務已經建立，這可能會花費數千（或數百萬）美元。如果以正確的方式完成，服務器緩存有助于處理這一切。它極大地系統化了整個事情。

了解不同類型的服務器緩存策略很重要，以便了解如何選擇正確的緩存策略。這是因為每個站點都不同，因此應該準備好為每個請求加載的人提供服務。但是，如果請求數量太大而無法處理怎么辦？突然的流量高峰怎么辦？它是否應該在特定時間限制后阻止進一步的客戶端請求？這甚至可行嗎？或者它應該學會在任何給定的時間點以某種方式為每個人服務？后者聽起來很有競爭力，不是嗎？必須熟悉不同類型的服務器緩存策略，才能選擇合適的緩存策略。以下是最常見的：

5 種不同類型的服務器緩存策略

1. 緩存旁白：在這種緩存策略中，緩存在邏輯上放在一邊，應用程序直接與緩存和數據庫通信，以了解請求的信息是否存在。緩存首先由應用程序檢查。如果找到該信息，則將其標記為緩存命中，然后讀取并返回給客戶端。如果信息不存在，則將其標記為緩存未命中。應用程序查詢數據庫以讀取數據，將讀取的數據返回給客戶端，然后將其存儲在緩存中以備將來緩存命中。

它最適合讀取繁重的工作負載。如果緩存服務器宕機，系統仍然通過直接與數據庫通信來工作；盡管在峰值負載有時突然出現的情況下，這從來都不是一個長期的解決方案。該緩存服務器需要將盡快修復。緩存和數據庫中的數據模型可以不同。

最常見的寫入策略是直接寫入數據庫。這就帶來了數據的不一致，為了解決這個問題，開發者一般會使用TTL（time to live），繼續服務，直到過期。它還可以與下一段中描述的其他服務器緩存策略協作。

2. 直寫緩存：在這種方法中，信息在主存/數據庫之前先寫入緩存。緩存在邏輯上位于應用程序和數據庫之間，客戶端通過它進行交互。因此，如果客戶端請求任何內容，應用程序不必檢查緩存是否可用，因為它已經在那里了。它直接從緩存中檢索并為客戶端提供服務。

不利的一面是，它增加了寫入延遲；但是如果與通讀緩存配對（接下來編寫的另一種策略），我們可以獲得數據一致性的保證。

3. 通讀緩存：在這種方法中，緩存位于數據庫內。每當出現緩存未命中（意味著請求的數據不在緩存中）時，缺失的數據將從數據庫中填充并返回給應用程序，以便為客戶端提供服務。

當多次請求同一組信息時，它最適合讀取繁重的工作負載。例如，需要許多人在不同設備上反復加載的新聞故事。

它的主要缺點是，如果第一次請求數據，它總是緩存未命中， 從而比正常加載速度太慢。開發人員通過手動發出查詢或通過直寫緩存來處理它。

4. 回寫：在這種服務器緩存策略中，應用程序將信息寫入緩存，立即確認更改，并在一段時間后將數據寫回數據庫。我們也可以稱之為write-behind。

對于寫入繁重的工作負載來說，這是一個很好的策略，可以提高寫入性能。它可以容忍適度的數據庫停機時間和不時發生的故障。它適用于read-through cache。如果支持批處理，則可以減少對數據庫的整體寫入，從而降低負載和成本。

在大多數關系數據庫存儲引擎中，例如 InnoDB，默認啟用回寫緩存，其中查詢首先寫入內存，然后刷新到主磁盤。主要缺點是，如果出現緩存故障，數據可能會永久丟失。

5. 寫字：在這種情況下，數據直接寫入數據庫，只有該數據存儲到讀取的緩存中。

它可以與read-through cache結合使用。在數據被寫入一次并且可以忽略或從不讀取的情況下，這是一個不錯的選擇。例如，當需要實時日志或聊天室消息時。它也可以與cache-aside混合使用。

上述類型的服務器緩存策略中的任何一種都沒有必要在實際使用中使用，但也可以結合使用兩種或多種以獲得最佳效果。如果有人剛開始處理這個問題，他們需要反復試驗才能提出最佳解決方案。以前使用的策略以后可能會過時。這就是為什么不能說一種特定的方法總是對每個人都有效的原因。